Securing Linux Users and Lessons Learned from the Snowflake Breach

Robert M.:
Okay. We are live. Hi, Sheetal. How are you?

Sheetal:
I'm good. Hi, Rob. How are you?

Robert M.:
I'm very good, thank you. Welcome to another IBA Friday, everybody. Happy Friday. On that note, for those of my Canadian friends that are on the call today, it's a couple of hours before the long weekend starts the day where we celebrate that we're not American. But shortly after that, Sheetal, you have July 4th in case you don't have it marked in your calendar, you have Thursday off.

Sheetal:
No, thank you. Thank you for the reminder.

Robert M.:
You're welcome. Today, Sheetal, we're going to talk about a couple things. We've got two topics that we want to cover with everybody today. The first one being another breach, right? It seems like every month or something. This one was with Snowflake, which is pretty significant. And then we're going to jump in and talk about some of our friends that are somewhat ignored in the security space, the Linux users. We're going to chat about them. Why don't we jump in and talk about Snowflake?

Sheetal:
Yes.

Robert M.:
Yeah.

Sheetal:
Rob, you tell us every month is one of these big breaches.

Robert M.:
Right.

Sheetal:
Tell us a little bit about what Snowflake does.

Robert M.:
Absolutely. Listen, before we get started, we should probably say this is not a slag against Snowflake. These mistakes continue to happen. It doesn't matter the organization, everybody other than 1Kosmos is secure. But in all seriousness, this is not to poke fun at Snowflake or anything like that. We're just looking at dissecting what happened and then how can we learn from and improve upon in the future so it doesn't happen to others, right? But listen, Snowflake, I think most people know who Snowflake is, but in case you don't or it's new to you, they're large data storage analysis firm that provides a platform for companies to drive intelligence and insights from the data that they're collecting on? Their customers.

Sheetal:
Customers, yes.

Robert M.:
Right. And that's where this gets a little bit tricky, right?

Sheetal:
Mm-hmm.

Robert M.:
Because there's so much data, customer data, that stuff becomes super important, super valuable to the bad guys, right?

Sheetal:
Mm-hmm. Which is what we like to call that honeypot, right? Some critical beautiful data in there, which is great for all these hackers. Tell us a little bit about the hacker organization, how the actual compromise happened.

Robert M.:
Yeah. Listen, the hacker guys have cool names, Scattered Spider and some other ones. This one was Shiny Hunters, okay.

Sheetal:
Mm-hmm.

Robert M.:
That's a cool name.

Sheetal:
Mm-hmm.

Robert M.:
But basically this happened by exploiting a weakness in the customer account security rather than a direct vulnerability that was found within the platform.

Sheetal:
Mm-hmm.

Robert M.:
Once they got the access, it's been reported that they found unencrypted usernames and passwords that the worker used to access an EPAM, E-P-A-M, customer Snowflake account, including an account for Ticketmaster. I think there was-


Robert M.:
There's another one, right?

Sheetal:
Mm-hmm. Santander.

Robert M.:
Santander, right? Yeah, exactly. The hacker says that the credentials were stored on the worker's machine and in a product management tool called JIRA. I think you're familiar with JIRA. Sheetal, I think you use that all the time, but the hackers are able to use those credentials, they say to access Snowflake accounts because the Snowflake accounts, guess what, Sheetal?

Sheetal:
Mm-hmm.

Robert M.:
Didn't require MFA.

Sheetal:
MFA, yes.

Robert M.:
Right?

Sheetal:
Really what happened was they found this file with unencrypted usernames, passwords, then they went ahead, logged in. None of these accounts had any MFA on them, which means that was easy-peasy for them to get in and have access to a volume of data. Tell us a little bit about the data that they actually had access to, Robert. What data really got compromised?

Robert M.:
Yeah. Listen, I mean, I think we're probably all Ticketmaster customers, right? I think we all know what Ticketmaster asks for, right? But the stolen data included bank account details for over 30 million customers, including 6 million account numbers and balances, 28 million credit card numbers and human resource information about staff. And that's all according to a post published by the hackers themselves. LendingTree and Advanced Auto Parts outside of Santander have also said they might be victims as well. Lots of data.

Sheetal:
Yeah. Lots and lots of great data, but I think what do we learn from these hacks, Robert? What's the takeaway from here?

Robert M.:
I mean, listen, we've been in the security space for a long time, right?

Sheetal:
Mm-hmm.

Robert M.:
And we all know that username and passwords are not the way to go. And here at 1Kosmos, we're trying to get rid of all that stuff, but at a minimum, we need to turn on MFA, right? We need to make sure to add another step to try to verify the identity of the person that's trying to authenticate. While MFA doesn't verify identity in the 1Kosmos sense necessarily, it does provide another roadblock to prevent a hacker from gaining access to something. At a bare minimum, I think at this point, this is another warning shot that if you don't have MFA turned on, go turn it on. Because at the end of the day, that's going to make your stuff just that much harder to get into. Or they'll go find somebody else that doesn't have MFA, excuse me, MFA turned on, but what did we learn? MFA, turn on MFA, right?

Sheetal:
Yep, absolutely. Okay.

Robert M.:
What about you? Did you get any takeaways from that?

Sheetal:
I think the initial compromise happened through a third party contracting firm, right? This basically means that your MFA and your security procedures probably need to go two levels deep. It's not just about making sure that your own organization and enterprise has MFA enabled. It's your enterprise, your third party contracting company's enterprise and finally it's about the customer. Make sure that the customer also has MFA turned so they are notified when there is an unauthorized access to their account, right? That was a big takeaway for me.

Robert M.:
Yeah. I mean, third party contractors, I mean, how many times have we heard about it? I think almost every other breach is because of a third party contractor. I mean, the issue from a security team is that you can't control what that third party's doing. You need to put things into place to make sure that they're at least following some sort of consistent security measure to help protect your own data, right? Yeah. Anyway, on that note, Sheetal.

Sheetal:
Yes.

Robert M.:
We said we're going to talk to some of our friends that-

Sheetal:
Get ignored.

Robert M.:
Don't typically get a lot of love. Here at 1Kosmos, we support a lot of different platforms. We do Windows, Mac, we do Android, we do iOS, we do Radius, we do FIDO, there's all kinds of different standards and flavors that we support. Linux is also one of those. Now Linux is not widely used. Why don't you tell me a little bit about Linux and how we or what we're doing there?

Sheetal:
Mm-hmm. Linux typically usually has a very small user base. If you look at any large enterprise, you know that they have multiple Linux servers deployed across their enterprise, and usually it's a small user base and it's heavily ignored, but you know that these small user base has access to some critical infrastructure. We're looking at databases that manage some very, very critical data like customer data or trading data if you're a financial organization, right? This is the data that's sitting behind any Linux server. They usually even have different kind of cron jobs or administrative tasks that are running behind the scenes. And this is typically what a setup for Linux really looks like. In every customer that we've met who's a large enterprise, they've always required Linux to be part of the package, right? How can we protect our Linux infrastructure with MFA and seamless MFA, right? Different MFA.

Robert M.:
Yeah. Those users, like you said, are typically looking after critical data, right?

Sheetal:
Mm-hmm.

Robert M.:
We just talked about the importance of managing critical data in the breach.

Sheetal:
Mm-hmm.

Robert M.:
What are we delivering to Linux users to try to help secure that environment now?

Sheetal:
I think some of the things is, hey, you have a lot of root users who have access to these critical servers. You want to make sure that when they performing some task, and usually it's an administrative task where they're either modifying a script or they're accessing this data, you have MFA in there, right? Our offering really, it's a basic setup that you're looking at. And even inside that setup, we are able to enable these users to require MFA. An MFA through just an email OTP, SMS OTP or through push, which means there is a device that's connected, which is receiving the notification and the user is able to gain access, right? The other thing that we've seen is, and this is a real world use case, where we were working with one of our case studies where we saw a whole bunch of power users or research users who had Linux desktops, right?

These are really power users. How do you give MFA to this setup? That's another use case where we were able to step in and empower these users to ensure that they have MFA in place. We want to make sure that any remote access through SSH, any database operations that are happening within a Linux server containing critical data or anyone who's performing a highly administrative task has MFA enabled. And I think finally what we want to stress on is service accounts, right? In most of these customer sites, what we've seen is there are services that are running behind the scenes that have no human intervention, right? And these are typically, they're very hard to get into, but there's always a user who's sitting behind the scenes managing that entire cron job as we like. A good example of it would be a financial institution who's trying to reconcile all the trades that happened on a particular day.

That's a good example of a cron job that's running. That service itself is running there, but there is an administrator who's sitting behind the scenes managing the entire operation. That user needs to have MFA, but your service account does not need to have MFA because... That's another use case that 1Kosmos can enable. We can sort of set it up to say that, hey, you know what? Your service accounts don't need MFA because they're completely hardened in a different location. Only certain accounts can access it, but the users, the real identities behind them require MFA. It's a beautiful flavor of MFA plus making sure it's adaptive. We're able to bring the entirety of having Linux inside your enterprise, right? That's what 1Kosmos has to offer.

Robert M.:
That's cool stuff. Obviously I'm going to ask, can you show this to us?

Sheetal:
Absolutely.

Robert M.:
There's two flavors of the Linux, like you said. It's awesome we're delivering something that these users can use, excuse me, and enterprises can implement, because like you said, a lot of the data that sits on a Linux server is typically pretty business critical stuff, right?

Sheetal:
Mm-hmm.

Robert M.:
You have a video, yeah?

Sheetal:
Yes.

Robert M.:
Yeah.

Sheetal:
I'm going to get my screen sharing together. Share screen. You able to see my screen, Robert?

Robert M.:
Yes.

Sheetal:
This video is extremely glamorous, Robert.

Robert M.:
Well, I mean it is Linux. There is the Linux that looks like a Mac or a Windows OS, but then there's Linux Linux, which is all code line, right?

Sheetal:
Yeah. This is a basic GUI interface. What you can see here is a customer who's trying to authenticate, they've provided their localhost username here, what we're doing is behind the scenes, we're validating the user's password. We can do both password-based MFA plus passwordless, right?

Robert M.:
Okay.

Sheetal:
Typically in the first step, you're either validating the user's password, and then what the 1Kosmos PAM or the authentication module does is it gives you different options. And you can see five different options here. They're pretty configurable. Meaning if you want to be a very tight-knit organization and say, I only want to enforce passwordless for all my Linux users, we are able to support that, right? You come in, you're selecting an option, which one of these options do you want? This one particularly, I think we've always been advocates of passwordless, so we're only going to look at what the experience look like if you had to do a passwordless experience, right?

Robert M.:
Okay.

Sheetal:
You'll see that the user is selecting number two, send push. And once they do send push, this particular user gets a push notification to the right on their mobile app. And once you do, what they're doing here on the mobile app is one, they are proving possession of the device itself at the time of onboarding. Second, they're also providing biometrics. It's a really secure form because it's something that you have, it's something that you know.

Robert M.:
Yeah.

Sheetal:
You're basically doing both of it, and then the user is given access. This is what our implementation of Linux looks like. It is fairly easy for us to retrain these users to say, hey, you know what? We're incorporating MFA into the process. Go ahead, give it a try. This is what we're protecting. And from an organization itself, any access entry point is a security threat. We're able to sort of give you that 100% coverage across your enterprise, across all your systems. That's really the big benefit here.

Robert M.:
That's cool. I mean, from a user experience standpoint, that's pretty easy, right? And it's something that users do. How many times do you pick up and look at your phone, Sheetal? I mean, you're always... You're not asking somebody to do something that they don't typically do anyway. And you've just infinitely improved the security that's sitting in front of your Linux desktops, which is pretty cool.

Sheetal:
Mm-hmm.

Robert M.:
Awesome.

Sheetal:
Absolutely.

Robert M.:
All right. That's it for our IBA Friday, Sheetal.

Sheetal:
Yeah. That's it.

Robert M.:
Thanks again. Where's your vest?

Robert M.:
The reason why. That's a bit of a joke, everybody. We went to Identiverse and every time I saw Sheetal, I'm like, Sheetal, where's your vest? She's like, I have it. Anyway, listen, thanks again for coming along and listening to our IBA Friday. We look forward to seeing you again soon. Sheetal, I'm going to enjoy my long weekend, and I hope you enjoy your long weekend next weekend.

Sheetal:
Okay, sounds good.

Robert M.:
See you later everybody.

Sheetal:
Bye-bye.